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incorporated by reference herein. Further, this application is related to U.S. Patent 
Application Serial Number 09/469,668, filed on December 22, 1999, entitled 
GPRS MAC PROCEDURES TO SUPPORT REAL-TIME SERVICES, assigned to 
the assignee of the present application, and hereby incorporated by reference herein.. 

20 

Background 

This application relates generally to a system and method for handing off a 
mobile node and more particularly to handoff mechanisms to support re al-time del ay- 
critical services in next generation wireles s networks. 
25 In data networks, such as Internet Protocol (IP) networks, users are typically 

assigned to a particular class of service (such as Platinum, Gold, or Silver) based on a 
service level agreement (SLA) with their service provider. In a fixed network, it is 
relatively easy to engineer and assign the user an appropriate amount of network 
resources so that the SLA can be maintained at all times. However, mobility and the 
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air-interface being utilized make the problem more difficult because th e network 
resources have toje reassigned-and/or,reneg otiate d as the user moves from o ne cel l 
to another. Additionally, the inherent hostile nature of the air-interface makes it 
difficult to predict and react accordingly to the changes in the radio frequency (RF). 
5 Historically, there have been two methods to support mobility across wireless 

cells. In the first method , the mob ile is in the full control of the decision making and 
the target -selection process ^ijejnovi ng from^one cell to the other. In Global 
Systems for Mobile Communications (GSM) or North American Time Division 
Multiple Access (NA TDMA) terminology, this process is known as reselec tion. In a 

1 0 re^iectj^pxoc.ess^t^ a master-sla ve relationship 

where the mobi le node decides which cell serves, its interest best. The network does 
not really have control over the target cell selection and so it is alerted to the mobile 
node's decision only after the target cell is selected. As a result, reselection is 
typically more time consuming from a network resource allocation point of view. 

15 Also, reselection during an active session requires the network to tem porarily buffer 
the datajgst ined forjhe mobile node. Additionally, the target cell may not even have 
enough resources to address the resource needs of the mobile node. 

In the second method, t he network, along with input from the mobile node, 
decides when and where to handoff the mobile node . Handoff refers to thetransfer of 

20 anjongoing wireless call from one t ransmission site (cell) to anoth er without 
disconnecting the call, This method requires constant monitoring of the mobile 
node's signal strength as well as c omplex jnanag ement o f targ et selection and 
network resourcje_assign ment Network directed handoff a lso requires more 
messaging over the air compared to reselection. However, this kind of mobility 

25 support can work faster because the target is known before the actual handoff takes 
placg^ Also, the resource allocation and appropriate reservation can be done at the' 
target to meet the mobile node's demand. In a variation of this scheme in GSM and 
NA TDMA, thejnoMej^e assistsjh sending it RF related 

information regarding the mobile npjiesljgigl^^ Th is facilitates the 

30 decision making process at the network and is call ed Mobile Assisted Hando ff 
(MAHO). 
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The reselection based mob^yworksjm^ mobile node is idle or in a 

non-real time active session. However, as previously mentioned, reselection may 

— — —) 

result in considerable dela ys. Thus, buffering data for a synchronous real time 

application (such as voice or video) during this delay interval is not recommended. 
5 Because t he reselection mechanism does not have any contro l over th e availability of 

the network resources at the target cell during the few seconds of reselection related 

delay, several voice packets may be dropped resulting in audible speech clipping. 

Additionally, in current data networks, the reselection process does not prioritize 
({^^resources based on the user's SLA. To address Quality of Service (QoS) 
10 requirements for real-time , delay-sensit ive multimedia services, the handoff 

mechanism needs to be optimized and enhanced in ne^geneiatioii-wireLe&Sjia^ (IP) 

network s. 

Therefore, an improved system and method is desired to reduce or eliminate 
the aforementioned complexities and limitations. 

15 

Summary 

In response to these and other complexities and limitations, provided herein is 
a unique system and method to support a handoff fcame.wprk for real-time dela y- 
critical services i n a next generation wireless data network. The system includes a 

20 c ore netwo rk (CN) and ajourcejind a target radio network subsystem (RNS). In one 
embodiment, the interface between the RNSs is enhanced to reduce unnecessary relay 
of messaging through the CN and thus will reduce traversing delays as well as the 
resources utilized in message processing. Two separate methods are proposed for 
handing off the data traffic to the target RNS at the CN packet processing node. 

25 These methods are a <^^rg ^t.funcUQ^ hat concurrently sends data to t he source 
RNS^and the^argetRNS, and a^suj wend/resumel^ctior? which sus pends the data 
flow towards the source RNS and resumes the flow towards t he tar g et RN S. 

In another embodiment, the source RNS reserves a first radio resource and 
detects a target RNS. The target RNS reserves a second radio resource, where an 

30 amount of the second radio resource is equal to that of the first radio resource. The 
first RNS then performs the handoff of a mobile node to the target RNS. 
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Advantages are described in greater detail with respect to the drawings and the 
remaining disclosure. 

Brief Description of the Drawings 

5 Fig. 1 is a diagrammatic view of a prior art communication system. 

Fig. 2 is a diagrammatic view of a communication system of the present 
invention for handing off a mobile node using multi-cast functionality. 

Fig. 3 is a diagrammatic view of a communication system of the present 
invention for handing off a mobile node using suspend/resume functionality. 
10 Fig. 4 is a computer of the present invention. 

Detailed Description 

Fig. 1 depicts a prior art communication system (network) 10 that includes a 
Core Network (CN) 12 that is coupled to Radio Network Subsystems (RNSs) 18-20 

15 via interfaces 22. The CN 12 performs several functions including managing a user's 
profile while the RNSs 18-20 perform r adio resource managemen t and hgndoff 
control. The RNSs 18-20 include nodes (not shown) that transmit and receive 
information to and from a mobile nodeJ4^ The RNSs 18-20 are also coupled to each 
other via interface 16 and may pass system related information between one another. 

20 According to Fig. 1, a relocation required message 24 is sent from the RNS 18 

to the CN 12 when the mobile node 14 needs to perform a handoff. T he CN 12 then 
sends a relocation request message 2_6 jo the RNS 20. In response, the RNS 20 sends 
a relocation request acknowledge message 28 to the CN 12 which sends a relocation 
command message 30 to the RNS 18. The RNS 18 then sends a relocation com mit 

25 message 32 to the RNS 20 whi ch indicates to the CN that the handoff has occurred, 
via a relocation detect message 34 and relocation complete message 36. Limitations 
of the system 10 are that it is centralized and controlled mainly by packet processing 
functions in the CN 12. 

Fig. 2 depicts a communication system 40 of the present invention that 

30 includes a CN 42 and RNSs 44-46 for performing handoff using the multicasting of 
messages. During the handoff process, it is important to maintain the user's QoS. As 
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such, according to the present disclosure, the following are identified as requirements 
during handoff in a next generation network (such as communication system 40, a 
3G.IP network, a 3G.PP network, and/or a 4G network): 

1. Minimizing the handoff delay for real-time, non-elastic applications (such 
as voice and video); 

2. Initiating handoffs at the right time to effectively manage RF related issues; 

3. Prioritizing handoffs based on the user's SLA and application being used; 

and 

4. Maintaining the SLA across the handoff boundary. 



Delay Minimization 

A primary objective for efficient hand-off for real-time services is the reduction of 
_dg|a^ This can be achieved in the following ways : 
a prior resource reservation for hand-off; 
15 - minimization of the number of messages that need to be exchanged to 

complete the hand-off process; and 
- c josely xoupling-the^S Qurce RN S (such as RNS 44) r elocati on processjvith 
t he movement of the user eq ui pment (UE) suc h as the mobile jiode 14, a 
laptop computer or any other device that can transmit and receive data to 
20 optimize the payload traffic route through the network. It should be noted 

that^scmrce RNS relocatior^nd hand-off are two separate processes. _l 

The entire hand-off mechanism can be divided into three broad sub-functions : 
1) Hand-off decision (which is not within the scope of this invention) 
25 2) Resource reservation (for both radio and wireline) 

3) Path switching. This will involve switching between nodes within the 
same RNS, as well as tha^between different RNSs^) 

The resource reservation and path switching functions will be discussed 

30 further. 
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Resource Reservation 

A new Media Access Controller (MAC) state machine for wireless data 
systems is proposed where a new "Packet Stand-by" s tat e has been a jded"tg?uppprt 
real-time, delay-sensitive service s, In such a scenario, the UE l^ lin gs^o^o^^^ 
5 (such as a reduced amount of) radio resourcemAe^acMt3tandrbv " state, despite 
the fact lhalthe appJication.dQesjioiJiayg^ any data to transit. This is re quired to, 
facilitate the rapid initiation of data transmission ( without going through the MACI 
contention mechanism to acquire a new channel) as soon as the appJicMio jQJSJsad^ to 
sgnd data ._ 

10 I n the case of hando ffioi^e^l-tiTrie se rvices, resource reseryationjs initiate d 

as^oon as the targeu|o^ _ j 

function. The amount of radio resource re^en#tion ij^ 



the UE 14 during handoff. A handof f controller interact s withajj^ 
Manager (RRM) to reserve the same amqunt.of resource/in theJar^tnode-that the 



/ 15 UE 14 was using [in the current node|( the handoff controlter^and^he^RRM are not 



V shown but are contained in each of the RNSs 44-46). Thus the UE 14 does not have 
to go through the resource contention phase even though it does not have data to send. 

Additionally, the resource "wastage" in the target node is minimized because 
resource allocation is based on the MAC state machine of the UE 14, and is not fixed. 
20 A "soft" reservation mechanism i s also use d such that the reserved reso urc e can be 
used by other low priority, jion-real-time services until the user requests d a ta to be 
transmitted. In that event, the lower priority traffic is pre-empted and the resource is 
allocated' to the user. Ifjhe RRM in the target node is not able to admit the handoff 



due to resource constraints, then the^QoS can be renegotiated) throughgxplicit 



25 messaging or viafa n implicit po licy decisions embedded in the user's SLA). For 
example, a user subscribing to " bronze " service can be either degraded or dropped, 
while a "gold" service subscriber may only be degraded, but never dropped. 

Path Switching 

30 When the mobile moves between node s (or cell sites) within the sameJlNJj, 

and assuming ea ch node is c onnected to a Radio Network Controller (not shown) in a 
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tree-like fashion^the path swit ching ,is handoff controller^ 

In case of^^^S Jia^^^ ^o cases-might arise : 

1) the mobile node 14 is always anchored at a serving RNS, and depends on 
RNS-RNS forwarding to receive or transmit^^^)This handoff scenario is 

5 not associated with source RNS relocation; and 

2) the mobile node 14 performs handoff with S RNS relocation. 

The handoff scenario that is not associated with the source RNS relocation is 
unsuitable foj^al=to^^^^because the path delay may increase proportionately 

10 with the forwarding (or tunneling) paths. This type of forwarding chain is generally 
not very scalable in IP networks due to the additional overhead of maintaining tunnel 
state information. Also, the current mechanism of performing source RNS relocation, 
which was described in Fig. 1, is unsuitable for real-time services. The source RNS 
relocation should be closely coupled with the actual hard handoff process and occur 

15 with minimal delay to reduce the "mute period" of real-time, delay-sensitive services 
during handoff. Thus it also makes sense to couple the source RNS relocation 
process with the^resource reservation function^(discussed earlier) for the sake of 
efficiency and reduction of delay. 

The present invention e nh^esj ^e jnterfage 16 bet\yegn the RNSs 18-20 in 

20 Fig. 1 to perforn^ 



interface 22 .This enhancement will reduce the unnecessary relay of,the^messagin 




through the CN 12 and thus will reduce the resources utilized in^mess age processin g^ 
and traversing delays. Two separate methods are proposed for handing _of f the^^^ r 
bearer) traffic^^^toget^^S (such as RNS 46) atthe CN 42 packet processing 
25 nodeTThese methods are a ^ulti^cafTOngioS to jhe source RN S a nd the tar gfilRNS, 
which is described further in Fig. 2, and a suspend/resume functio n ( suspending the 
Jlowjowards the.source RNS, and resumin g the flow tow ^ds thejtarget RNS) at the 
CN 42, which is described further in'Fig. 3. 

Referring again to Fig. 2, in operation, th e source RNS 44 decides on a target 
30 RNS 4 6 ^tnk target RNS selection is closely coupled jYithJh^handofLthreshold 
detection ) anfl sends a Relocation R^ugstJBgsaage_27 to the target RNS 46 via the 
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enhanced interface 17. The Relocation Req uest m essag e 27 is enhanced to contai n 



details of the r adio access bearer identifier, res ource reservation information (as 
.^^^discussed above), an IP address of the packet processin g node serving the UE 14 in 

theCN 42 ^as well as anyjaplink^ source RNS 44 sends 

5 a R elocation Started message 48 to the packet processing node serving the UE 14 in 
the CN 42. Upon receiving the Relocation St arted message 48^ the CN 42 waitsjbr a 
Relocation req uest ZlgK message toj be rec eived from the tar g et RNS 46. The target 
RNS 46^e serves the radio resourgesjand b i -casts the Relo cation requ est ACK -f^t 
message 29 Jo the packet processing_node in the CN42„and.toJhe.source RNS 44. 
10 Th i s message_29 will contairUhe IP address of the pack et proces sing functign^ 

allocated to the UE 14 w itMnthet arget RNS 46 and sets up the tunnel to the CN 42 
for the uplink packets. The CN 42 sets up the tunnel for downlink packets (which is a 
duplicate copy of the tunnel towards the source RNS 44) tow.adsJhelargel.RNSjl-6., 
T he CN 42 then begins to3i^cast-the,downlink.packets_to.wards the ,sourc.e_RNSJ4. 



15 J and the ta rget RNS 46. These pack ets are buffered by jh£lax£ £t RNS 46. I n the 

^ ^^^neantime, the sou rce,RJJS-44-ha ndoff controller (not shown) completes the haqdjoi £ 

A process to the target cell (not shown) w hich is within the target RNS 46. T he source 
jO/y , - ~— 

r 7 ^/^ v RNS 44 transmits to the target RNS a Relocation Commit message 33 that contains 

information regarding the last packet that has been sent to the UE 14. The target RNS \JL} 
20, 46 starts then starts transmitting to the UE 14 from the next packet onward£jn~its q ^ 

buffer^ (i^^C 

In order to achieve a smooth handoff, the CN 42 (especially if it is non-QoS 
guaranteed) and a network between the RNS's 44-46 (such as a public EP network 
with no guarantee on delay) should be well-engineered to ensure that the above 
25 - messages described in Fig. 2 do not take a long time to reach their destinations thus 
prolonging the mute period during handoff. If this engineering is not possible, a mute 
buffer can be used at the target RNS 46, with a mute period estimated from network 
delay behavior. If the mute buffer solution is utilized, the Relocation Commit 
message 33 may not need to contain the information regarding the last packet that 
30 was sent to the UE 14. 



8 



Fig. 3 describes the suspend/resume function at the CN 42. Similar to the 
steps described in Fig. 2, in operation, the source jNS 44_deci des on the target RNS 
46 and sends a Relocation Request message 27 to the target RNS 46 via the enhanced 
interface 17. The Relocation Request message 27 is enhanced to contain details of 
5 the radio access bearer identifier, resource reservation information (as discussed 
above), an IP address of the packet processing node serving the UE 14 in the CN 42, 
as well as any uplink tunnel state information. The source RNS 44 sends a 
Relocation Started message 48 to the packet processing node serving the UE 14 in the 
CN 42. Upon receiving the Relocation Started message 48, the CN 42 waits for the 
10 Relocation request ACK message to be received from the target RNS 46. The target 
RNS 46 reserves thej;ad^^q^^^S_bi^^^^ie Relocationj^uest^ACK_ 
message 29 to the packet processing node in jhe CN 42 and to the jource RNS 44. 
This message 29 will contain the IP address of the packet processing function 

allocated to the UE 14 within the target RNS 46 and sets up the tunnel to the CN 42 

> 

15 for the uplink packets. The CN 42 sets up the tunnel for downlink packets towards 
the target RNS 46. The CN 42 then begins to bi-cast the downlink packets towards 
the source RNS 44 and the target RNS 46. These packets are buffered by the target 
RNS 46. In the meantime, the sou rce RN S 44 han doff control ler (not shown) 
completes the handoff process to the target c ell (not shown) which is within the target 

20 RNS 46. The source RNS 44 transmits to the CN 42 the Rel ocation Commit message 

7/ " " 5 " " 

/ 

33 that contains information ^ggaghng the last pac ket that has be en sent to the UE 14. 
^T he CN 42 suspends traffic flow towards th e s ource RNS 44 and resumes , 
transmissio n towards the tar get RNS 46. 

In this scenario, if the network engineering to ensure that the above messages 
25 described in Fig. 3 do not take a long time to reach their destinations is not possible, 
no mute buffer would be required at the target RNS 46. 

Fig. 4 depicts a computer 60 that comprises a processor 62 and memory 64. 
The computer 60, which contains a computer program, may be a personal computer 
or laptop, the CN 42, the RNSs 44-46, the UE 14, and/or any device that can transmit 
30 and receive handoff related information. The processor 62 may be a central 
processing unit, digital signal processor, microprocessor, microcontroller, 
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microcomputer, and/or any device that manipulates digital information based on 
programming instructions. The memory 64 may be read-only memory, random 
access memory, flash memory and/or any device that stores digital information. The 
memory 64 is coupled to the processor 62 and stores programming instructions 
5 (contained in the computer program) that, when read by the processor 62, cause the 
processor to perform the functionality discussed above with reference to Fig.'s 2 and 
3. 

The present invention thus enjoys several advantages. For example, two 
methods are proposed for handing of f data traffic to a target RNS. These methods, 

10 the multi-cast function and the suspend/resume function, achieve two fundamental 
purposes: closely coupling the hand-off process (with resource reservation) with the 
source RNS relocation process to reduce hard handoff latency for real-time services, 
and making the source RNS relocation more efficient by reducing the amount of 
messaging and the involvement of the CN. 

15 It is further understood that other modifications, changes and substitutions are 

intended in the foregoing disclosure and in some instances some features of the 
disclosure will be employed without corresponding use of other features. 
Additionally, singular discussion of items and/or computers located in the system 40 
is also meant to apply to situations where multiple items and/or computers exist. 

20 Further, the system 40 may include additional and/or fewer items and/or computers 
that perform similar functions discussed in the disclosure. Accordingly, it is 
appropriate that the appended claims be construed broadly and in a manner consistent 
with the scope of the disclosure. 
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